The present disclosure relates generally to establishing a secure exchange of data between containerized applications. In particular, the disclosure relates to the secure exchange of data between containerized applications running on a same device and registered to a same access server, such an Oracle Mobile Security Access Server.
When an application, such as a containerized application, is installed on a device, such as a mobile device, the application is launched. A user of the device will be asked to authenticate themselves with the access server in order to determine if they are an authorized user. If the user is authenticated, they will be allowed to access the application and its data. If another application, such as a containerized application, is installed on the device and is registered to the same access server, and the application has already been authenticated and holds a session token and a data encryption key (root-Key), then a single sign-on (SSO) can be performed between the applications.
SSO is the ability for a user to enter the same ID and password in order to logon to multiple applications within an enterprise. An access manager may manage access to one or more resources by implementing a SSO system. The SSO system may provide a SSO session that enables an authenticated application to access protected resources to which the application is entitled to access.
Data can be shared between applications by using intents and broadcasts. An intent or parcel is a message package that can provide a facility for performing late runtime binding between the code in different applications. An intent can be used to, for example, start an activity, start a service, and/or deliver a broadcast. An intent can be a passive data structure holding an abstract description of an action or topic. For example, an intent can contain a message. A broadcast can be a message that an application can receive. A system can deliver various types of broadcasts for system events.
Intents and broadcasts can be registered on an action, such as a custom action. A custom action can be defined by, for example, a developer. An action is a general action to be performed. Actions can include, for example, displaying information, editing information, etc. When an application launches an intent and broadcast on an action, other applications listening for that action can receive the intent, which contains a message that is broadcasted on the action.
However, if a rogue application or unauthorized application also registers itself on the same action, the rogue application can receive the intent and broadcast and would be able to access all of the data that is present in the intent. Therefore, data on intents and broadcasts needs to be protected from rogue applications.
The message exchange between the applications can be secured by using a signature level protection. Signature level protection is used in, for example, Android® applications. By using signature level protection, a second application can be allowed to communicate with the first application only if the second application is signed by the same signer or if the second application has the same signing certificate as the first application.
However, same signer information may not be possible. For example, containerization tools for mobile application management systems, such as an Oracle Mobile Security Suite (OMSS) containerization tool, can be used to containerize any third party application. The containerized applications can then be uploaded to application stores and used by users. These containerized applications will consequently have different signer information from other applications. Therefore, a message exchange will not work between applications since the applications will not have the same signer information.